Multiple services allow text-based commands in a request-response format. Each of these services has different syntaxes for requests and responses. A middleware application acts as a translator, allowing a user to interact with one or more of these services using one syntax. This middleware application first converts simple requests from the user into complex commands for one or more of the multiple services, and then converts the detailed responses from the one or more of the multiple services into a simple response for the user.
One example of an middleware application, as described above, is an Instant Message Java 2 Enterprise Edition application, developed for use with IBM WebSphere Application Servers. The middleware application operates an Instant Message Framework (“IMF”) and at least one Instant Message Service (“IMS”). The IMF directs instant messages to the IMS. The IMS is a translator that converts instant messaging (IM) requests into a complex command usable by a remote service, and converts the response from the remote service into a simple instant message. A separate IMS is required for each remote service accessible through the IMF. The remote service can be located on the same server as the middleware application, or can be located on another server, accessible through a local network or the Internet.
The IMF supports the Session Initiating Protocol (“SIP”) which is a standardized way of managing requests and responses between multiple applications using instant messaging. SIP allows users of various IM clients, such as personal computers, cellular phones, telephone voice recognition services, etc., to access the IMF.
The IMF validates incoming instant messages, identifying instant messages that contain requests related to an IMS. If the instant message contains a request related to an IMS (called a token), the IMF forwards the instant message to the proper IMS. The IMS transforms the simple IM requests into a complex command and sends the complex command to the intended remote service. The IMS then takes the response to the complex command and converts the response into a simple instant message. The IMS sends the simple instant message back to the IMF, which directs the simple instant message to the initiating client.
As an example, a user creates the instant message “weather 75201” on a cellular phone that supports SIP and sends the instant message to the middleware application. The middleware application identifies the instant message as using SIP, and routs the message to the IMF. The IMF identifies the term “weather” as a token indicating that the message is intended for the weather IMS, so the IMF forwards the instant message to the weather IMS. The weather IMS interprets the instant message as a request for a weather forecast for the 75201 zipcode. The weather IMS transforms the request into the proper format to retrieve weather information from a remote weather website. The remote weather website returns a response to the weather IMS. The weather IMS transforms the response into a simple instant message, which is returned to the IMF. The IMF then sends the instant message containing the response back to the user's cellular phone.
Different users have different expectations and requirements for these types of IM interaction. For example, a software developer requesting the status of a particular computer server might want to know details about the memory usage, up time, and CPU usage, while an administrator requesting the status of the same computer server might only care to know that it is up and running within desired parameters. Similarly, a traveler may desire a different response to the same simple flight information request depending on where the traveler is. For example, if requesting flight information from a networked laptop computer, the traveler may want to display the weather for the destination city and a map of the airport, but the same traveler making the same request from a cellular phone may prefer a text message with just the departure time and gate number. Thus, a need exists for a way to customize how the middleware application handles simple IM requests and responses based on the personal preferences of a user.